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DISPOSITIF ET PROCEDE DE CONTROLE D'ACCES A DES 

RESSOURCES 



La presente invention concerne un dispositif et un procede de 
controle d'acces a des ressources d'un systems informatique. 

L'art ant^rieur 

Les systemes informatiques disposant d'un tres grand nombre de 
ressources reparties geographiquement necessitent desormais de nombreux 
administrateurs pour leur gestion. Chaque administrateur est proprietaire de 
droits d'execution de commandes privilegiees sur des ressources 
determinees. 

Un probleme pose par Tinvention est de controler les droits des 
administrateurs dans un systeme informatique et d'empecher ceux qui n'ont 
pas regu Tautorisation adequate d'effectuer des actions sur des ressources 
donnees. 

De plus, le nombre de ressources dans , un systeme informatique 
s'accroit rapidement. De ce fait, le controle d'acces est rendu complexe 
compte tenu du nombre important d'informations a gerer. 

Actuellement, pour repondre a de tels problemes, les systemes 
informatiques comprennent au niveau de chacune des ressources gerees 
une liste de controle d'acces specifiant fes droits d'administrateurs ou de 
groupes d'administrateurs identifies, d'effectuer une action donnee sur la 
ressource concernee. Les droits des administrateurs ou groupes 
d'administrateurs sont precises ressource par ressource. La liste des droits 
associes a une ressource est enregistree dans un fichier associe a ladite 
ressource. Lorsqu'une application lancee par un administrateur donne 
souhaite acceder a une ressource, le systeme consulte la liste qui est 
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rattachee a la dite ressource et verifie si ledit administrateur a le droit d'y 
acceder. 

Un tel systeme est base sur I'identite de radministrateur et plus le 
nombre d'administrateurs augmentent, plus le systeme se complexifie, plus il 
deviant lent et coCiteux. Par ailleurs, le systeme necessite d'acceder a la 
ressource interrogee meme si radministrateur appelant n'a pas les droits 
suffisants requis pour ce faire et que la demands de radministrateur est 
finalement rejetee. II en resulte un temps de reponse important. 

Un but de la presente invention consiste a simplifier le procede de 
controle d'acces a des ressources d'un systeme. 

Un autre but de I'invention est d'eviter recces systematique aux 
ressources interrogees pour verifier les droits de Tappelant et autoriser 
Tacces auxdites ressources. 

Resume de I'invention 

Dans ce contexte, la presente invention propose un procede de 
controle dracoes d'un demandeur a des ressources dans un systeme 
informatique, caracterise en ce qu'il consiste a definir des roles recouvrant 
un ou plusieurs privileges et representant une competence du demandeur 
pour realiser des taches specifiques, a enregistrer les roles definis dans des 
moyens de stockage, et a enregistrer une lists de controle d'acces 
definissant les conditions d'obtention d'un droit sur un type de ressource, a 
savoir d'une permission configuree en terme de privileges dans lesdits 
moyens. 

La presente invention concerne egalement le systeme de mise en 
oeuvre dudit procede. 



Presentation des figures 



D'autres caracteristiques et avantages de r invention apparaitront a la 
lumiere de la description qui suit, donnee a titre d'exemple illustratif et non 
limitatif de la presente invention, en reference aux dessins annexes dans 
lesquels: 

•la figure 1 est une vue schematique d'une forme de realisation du 
systeme selon Tinvention ; 

•la figure 2 represente une forme de realisation de la liste 
representee sur le figure 1 ; 

•la figure 3 est un exemple de la liste representee sur la figure 2. 

•la figure 4 est un tableau d'exemples de groupes generiques de 
droits et ressources. 

Description d'une forme de realisation de Tinvention 

Le systeme informatique peut etre un systeme dont Tenvironnement 
est de type distribue ou local. 

Comme le montre la forme de realisation du systeme selon Tinvention 
illustree sur la figure 1 , le systeme informatique 1 est distribue et compose 
de machines 2a, 2b, 2c, 2d organisees en un ou plusieurs reseaux 3. Une 
machine 2 est une unite conceptuelle tres large, de nature materielle et 
logicielle. Les machines peuvent etre tres diverses, telles que des stations 
de travail, serveurs, routeurs, machines specialisees et passerelles entre 
reseaux. Seuls les composants des machines 2 du systeme 1 
caracteristiques de la presente invention seront decrits, les autres 
composants etant connus de Thomme du metier. 



Comme ie montre la figure 1 , dans la presente invention, le systeme 
informatique 1 comprend au moins une machine 2a dite machine 2a cliente, 
au moins une machine 2b de stockage de securite centralisee, au moins un 
serveur 2c d'administration, au moins une machine 2d ,de ressource 
administree. II est a noter que les machines 2 sont susceptibles d'etre 
regroupees les unes aux autres, ainsi par exemple, la machine 2b de 
stockage et le serveur 2c d'administration peuvent ne former qu'une seule 
machine. 

La ressource 2d est entendue au sens large, a savoir toute entite, 
logique et/ou physique, accedee et manipulee par des machines 2a cliente. 
La ressource se presente a titre illustratif sous la forme d'une imprimante, un 
fichier... La ressource 2d est, dans I'exemple decrit, caracterisee par un 
type, et eventuellement un identifiant. Un type de ressource regroupe un 
ensemble de droits qui s'appliquent a toutes les ressources de ce type. 
L'identifiant est constitue par exemple par un nom, un chemin d'acces... 

A titre illustratif, la ressource 2d est une imprimante de type 
« imprimante reseau » et ayant pour identifiant le chemin de la ressource 
« \\mao.dom\bleuet ». Selon un autre exemple, la ressource 2d est une base 
de donnees de facturation de Louveciennes de type « base de donnees » 
ayant pour identifiant le nom de la base de donnees 
« database_facturation.frlv.bull.fr ». Le type « base de donnees » regroupe 
par exemple les droits suivants : « demarrer », « arreter », « configurer », 
etc. 

Un critere de controle d'acces est une propriete de la ressource 2d 
utilisee pour realiser le controle d'acces sur cette ressource. Le critere 
identifie de maniere unique une ressource particuliere ou un ensemble de 
ressources. Les proprietes de la ressource susceptibles d'etre utilisees 



comme criteres sont par example le type de ta ressource, le chemin ou la 
combinaison des deux. 

La machine 2a cliente comprend au moins une entite 4 appelante. 
une interface 5 de programmation applicative (API), un service 6 de ccntrole 
d'acces (appele RAC). L'entite 4 appelante, I'API 5 et le RAC 6 sont 
susceptibles de faire partie d'une unique machine 2 ou de machines 2 
differentes. 

L'entite 4 appelante represente dans ce qui suit toute entite logique 
et/ou physique effectuant un ensemble de procedures et traitements et 
susceptibles de necessiter Tacces a une ou plusieurs ressources 2d. L'entite 
4 appelante se presente par exemple sous la forme d'une application, un 
fichier, une commande, 

Un demandeur 7 lance Tentite 4 appelante et requiert I'autorisation 
d'effectuer une action dans le cadre de cette entite 4 sur une ressource 2d. 
Le demandeur 7 est une personne physique et dans la forme de realisation 
illustree un administrateur. Dans exemple illustre, l'entite 4 appelante se 
presente sous la forme d'une application et la ressource 2d d'une base de 
donnees : la machine 2a cliente traite la question de savoir si 
radministrateur 7 operant sur ladite application 4 a le droit d'effectuer une 
action sur une base de donnees 2d. Le demandeur ne peut acceder a ladite 
ressource 2d que si il dispose de droits suffisants. 

Un droit designe une ou plusieurs actions ou commandes effectuees 
par un demandeur 7 dans le contexte d'une entite 4 appelante, d'une 
ressource 2d ou d'un ensemble de ressources 2d. Pour un demandeur 7, le 
droit est global ou specifique a une ressource 2d, et dans ce dernier cas, il 
definit un type d'acces particulier a la ressource 2d concernee. Par exemple, 
dans le contexte de bases de donnees, un administrateur peut avoir le droit 



d'arreter ou de demarrer des bases de donnees particulieres selon son role 
et ses privileges d'administration. 

Uentite 4 appelante regoit de demandeurs 7 des requetes d'acces a 
des ressources 2d. Selon une forme de realisation particuliere, I'entite 4 
appelante offre au demandeur 7 une interface graphique 8 par 
rintermediaire de laqueile le demandeur 7 saisit sa requete. L'API 5 
transmet interrogation de Tentite 4 appelante au RAC 6. L'API 5 fait 
Tinterface entre Tentite 4 appelante et le RAC 6 auquel elle est associee. Le 
RAC 6 controle Tacces des demandeurs 7 aux ressources 2d interrogees. 

L'API 5 offre notamment des fonctions d'acces au RAC notamment 
pour la prise de decision en reponse a la question posee par I'entite 4 
appelante. 

Le RAC 6, comme le montre la figure 1, comporte trois modules 
fonctionnels : 

• un module 9 d'acces a des moyens 10 de stockage et plus 
particulierement dans la presente forme de realisation, a des 
moyens 10 d'enregistrement de roles, privileges et domaines de 
validite du demandeur qui seront definis dans ce qui suit ; 

• un module 11 d'acces a des moyens 12 de stockage, et plus 
particulierement dans la presente forme de realisation, a des 
moyens 12 d'enregistrement de listes de controle d'acces des 
demandeurs permettant de charger les listes de controle dracoes 
se presentant sous la forme de fichiers, ou autres moyens de 
stockage ; le module 1 1 est appele dans ce qui suit le RAD. 

• un moteur 13 d'autorisation. 

Le systeme selon la presente invention est base sur une 
caracteristique particuliere des demandeurs 7, a savoir leur role dans 



rentreprise, et plus particulierement (exemple illustre) dans radministration 
des systemes informatiques de Tentreprise. Pour definir le role d'un 
demandeur. il est tout d'abord necessaire d'expliciter ce que represente un 
privilege. 

Un privilege est un attribut de securite d'un demandeur 7 pour 
permettre le controle d'acces de ce dernier a des ressources 2d. Chaque 
ressource dispose d'une liste propre de privileges ; il est egalement 
susceptible de prevoir des listes de privileges communs a plusieurs 
ressources ou a tout le systeme. Le privilege est attribue a un demandeur 
directement ou indirectement par Tintermediaire d'un role. Par exemple, un 
administrateur peut se voir attribuer le privilege « admin_db » 
d'administrateur de base de donnees, privilege qui lui permet de demarrer 
tout type de base de donnees (figure 3). 

Un role est constitue d'un ensemble de privileges : il recouvre une 
connotation metier et represente une competence pour realiser un ensemble 
d'activites et de taches d'administration. Ainsi, par exemple, le demandeur 
« Dupont » a pour role (metier) administrateur de Tapplication de 
facturation : au niveau du systeme, le demandeur « Dupont », compte-tenu 
de son role d'administrateur de I'application de facturation. dispose des 
privileges « administrateur de base de donnees » (« admin_db »), 
« super_db », « operateur reseau », « installateur de logiciel a distance », 
« operateur systeme ». 

L'ensemble des privileges dans un role donne sert de base pour 
controler les actions d'un demandeur. Un demandeur se voit attribuer un ou 
plusieurs roles. Le demandeur 7 definit de nouveaux roles ou modifient des 
roles existants en ajoutant ou supprimant des privileges. 
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Les listes de controle d'acces enregistrees dans les moyens 12 
d'enregistrement definissent les conditions d'obtention de droits d'acces sur 
des ressources rattachees a des entites 4 les gerant : el les offrent une 
interface basee sur des permissions configurees. 

Une permission est une association d'une ressource a un droit. Par 
exemple. une permission peut etre d'arreter (droit) une base de donnees 
particuliere (ressource). La permission represente un type d'acces, une 
action ou une operation particuliere dans le contexte d'une entite 4 
appelante ou d'une ressource 2d de Tentite 4 appeiante en question, 

Les permissions sent de deux types : les permissions demandees et 
les permissions configurees. 

•Les permissions demandees sont des questions posees par une 
entite 4 appelante au RAC 6. Les reponses a ces questions permettent aux 
entites 4 appelantes de savoir si un droit d'acces est a autoriser au 
demandeur dans le contexte courant d'utilisation de Tentite. 

•Les permissions configurees definissent un mode d'acces possible 
sur une ou plusieurs ressources, comme vu plus haut. Les permissions 
configurees sont enregistrees dans la liste 12. 

Les conditions d'obtention de permissions sont exprimees sous forme 
de combinaisons de privileges. 

Les listes de permissions et conditions d'obtention de ces 
permissions sont constituees de lignes, appelees entrees. La figure 2 
represente une entree d'une liste. L'entree exprime les permissions 
configurees et les conditions d'obtention de droit sur une ressource en terme 
de privileges requis. L'entree comprend trois colonnes : une colonne droit, 
une colonne ressource, les colonnes droit et ressource formant la 



permission configuree, et une colonne privilege. Selon une forme illustrative 
de rinvention. la ressource est identifiee par son type ; le type est le critere 
de controle d'acces. 

Les droits ou les ressources sont susceptibles d'etre regroupes en 
groupes generiques representes par des filtres sous forme de caracteres 
speciaux tels qu'une etoile « * » ou par des mots-cles tels que le mot 
« any ». Le mot-cle « any » signifie par exemple tout privilege. Le tableau de 
la figure 4 indiquent des exemples de signification du filtre etoile * Le filtre 
« etoile » applique a un droit de format « xyz* » signifie tout droit dont le nom 
commence par xyz. Le filtre « etoile » applique a un type de ressource de 
format « mytype* » signifie toute ressource dont le type est mytype. Le filtre 
« etoile » applique a un chemin de ressource « /abc/def/* » signifie toute 
ressource dont le chemin est un sous-ensemble de /abc/def/. 

Les filtres et mot-cles permettent de regrouper un grand nombre 
d'entrees en une seule et de faciliter de ce fait radministration de la 
configuration. 

Dans la forme de realisation decrite, une entree dans la liste 
represente des acces autorises. Selon un developpement de I'invention, une 
entree contient egalement des permissions negatives. 

Le systeme selon la presente invention permet de restreindre les 
ressources accessibles pour un role donne a une partie uniquement de 
Tensemble global des ressources 2d au moyen d'un domaine de validite du 
role. Un domaine de validite definit une partie d'un ensemble de ressources 
2d. accessible pour un role donne. Si les instances des ressources sont 
organisees hierarchiquement dans un arbre, une collection de branches de 
ressources determine un domaine de validite. 
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Une information supplementaire relative a la necessite de consulter le 
domaine de validite est prevue dans I'entree de la liste pour eviter la 
comparaison systematique du domaine avec le chemin de la ressource 
concernee. La comparaison n'est pas necessaire lorsque le domaine de 
validite correspond au chemin de la ressource. L'information en question 
consiste en un booleen (oui-non) exprimant la necessite de consulter ou pas 
le domaine de validite. 

La figure 3 represente une liste de controle d'acces incluant le champ 
relatif a la necessite de consulter le domaine de validite : ce champ est 
nomme domaine. Pour qu'un administrateur muni du privilege super-bd 
puisse arreter dans la base de donnees, le RAC doit verifier que le chemin 
de la ressource correspond au domaine de validite ce qui n'est pas le cas si 
I'administrateur souhaite demarrer dans la base de donnees. Dans ce 
dernier cas, I'administrateur peut demarrer toute base de donnees sans 
restriction. 

Le RAC 6 attribue une valeur par defaut aux champs non renseignes 
d'une entree de la liste. 

Selon une forme de realisation illustrative de I'invention. les valeurs 
par defaut sont : 

•Pour le type de ressource : * (tout type de ressource : un droit 
associe au type de ressource * signifie que le droit s'applique a tout type de 
ressource) ; 

•Pour le droit :* (tout droit : un droit * associe a une ressource signifie 
que tout droit s'applique a ladite ressource) ; 
•Pour le domaine : oui ; 

•Pour les privileges requis : any (aucun privilege n'est requis pour le 
droit demande). 



> • • 

11 

Les donnees de securite d'un demandeur sont constituees d'un ou 
plusieurs roles associes a un ou plusieurs privileges et de maniere 
optionnelle, a un domaine de validite du role. 

Les donnees de securite d'un demandeur sont a distinguer de la liste 
des controles d'acces dans laquelle sont decrites les conditions d'obtention 
d'un droit sur une ressource en terme de privileges requis et en terme de 
necessite ou pas de consulter le domaine de validite du role. Les donnees 
de securite sont enregistrees dans les moyens de stockage 10 et la liste de 
controle d'acces dans les moyens de stockage 12. 

Le systeme selon la presente invention fonctionne de la maniere 
suivante. 

Lorsque le demandeur 7 lance Tentite 4 appelante, il selectionne un 
role d'administration parmi ceux proposes par I'interface graphique 8 jusqu*a 
sa deconnexion de ladite entite 4. Dans I'exemple pris tout au long de la 
description qui suit, le demandeur « Dupont » est un administrateur qui 
selectionne le role administrateur de Tapplication de facturation. 

Le demandeur 7 demande a effectuer une action sur une ressource 
donnee. Par exemple, I'administrateur Dupont souhaite arreter la base de 
donnees de facturation de Louveciennes dont le nom est 
« database_facturation.frlv,bull.fr ». 

Lorsque I'entite 4 appelante doit decider d'autoriser ou refuser une 
action du demandeur 7 sur une ressource 2d determinee, elle pose sur la 
base de I'identite du demandeur la question a I'API 5. Uentite 4 appelante 
demande une permission a I'API 5 ce qui constitue une permission 
demandee (comme vu plus haut). 
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Uentite 4 appelante soumet a I'API 5, a titre illustratif, la question 
suivante : 

« est-ce que radministrateur Dupont a le droit diameter la ressource 
base de donnees de facturation de Louveciennes dont le nom est 
« database_facturation.frlv.bull.fr » ? ». 

A reception de ladite question et au premier appel de I'API 5, le RAC 
6 recherche le role et la liste des privileges du demandeur 7 au moyen du 
module 9 d'acces aux privileges. Dans I'exemple, le demandeur 7 a 
notamment pour role « administrateur de base de donnees » et pour 
privileges associes « super_db » et « admin-db ». Le role « administrateur 
de base de donnees » a pour domaine de validite les bases de donnees 
dont le nom finit parfrlv.bull.fr a savoir « *.frlv.bulLfr ». 

Le precede effectue deux niveaux de controle, le second etant 
conditionnel par rapport au premier : 

• un premier niveau sur les types de ressources ; 

• un deuxieme niveau sur i'identifiant de la ressource. 

Lors du premier niveau de controle, le RAC 6 consulte la liste des 
controles d'acces (figure 2) a Taide du RAD 11. Un extrait de ladite liste 
selon I'exemple illustre est donnee sur la figure 3. Le moteur 13 
d'autorisation du RAC 6 vehfie qu'il existe au moins une entree de la liste 
qui satisfait les conditions d'obtention du droit demande, a savoir qu'elle 
contient les trois elements suivant, ladite ressource, le droit demande et I'un 
au moins des privileges du demandeur. 

Si les conditions d'obtention du droit ne sont pas satisfaites, a savoir 
qu'aucune entree de la liste ne contiennent les trois elements requis, le RAC 
6 via TAP! 5 repond par la negative a la question de I'entite 4 appelante. 
L'entite 4 appelante indique au demandeur 7 qu'il n'a pas le droit d'effectuer 
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raction demandee sur la ressource concernee, en I'espece d'arreter la base 
de donnees de facturation de Louveciennes. 

II est a souligner que le demandeur est infornne qu'il ne peut effectuer 
une action determinee sur une ressource donnee avant tout acces a ladite 
ressource. 

Si les conditions d'obtention du droit sont satisfaites, a savoir qu'une 
ou plusieurs entrees de la liste contiennent simultanement les trois elements 
requis, et que par aiileurs le domaine de validite dans la ou les entrees 
concernees ont la valeur « non », aucun controle supplementaire n'est 
requis, Uensemble des ressources concernees sont accessibles pour le role 
donne. Le RAC via TAPI repond par la positive a la question de I'entite 4 
appelante. L'entite 4 appelante autorise le demandeur 7 d'effectuer Taction 
demandee. en I'espece d'arreter la base de donnees de facturation de 
Louveciennes. 

Si les conditions d'obtention du droit sont satisfaites, a savoir qu'une 
ou plusieurs entrees de la liste contiennent simultanement les trois elements 
requis. et que par aiileurs le domaine de validite dans la ou les entrees 
concernees ont la valeur « oui », le precede passe au deuxieme niveau de 
controle. C'est le cas dans I'exemple traite : la premiere entree de la liste de 
la figure 3 satisfait les conditions d'obtention du droit demande par 
radministrateur : le droit est celui d'arreter, le type de ressource est une 
base de donnee et le privilege requis est super_db. 

Lors du deuxieme niveau de controle, afin de determiner si le role en 
question peut effectuer Taction requise sur ladite ressource, le moteur 13 
d'autorisation realise un controle sur le domaine de validite associe au role 
courant si les trois conditions suivantes sont reunies : 
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• la permission demandee contient un identifiant de ressource (nom, 
chemin) ; en effet, si le demandeur souhaite demarrer une base de 
donnees, la reponse ne peut qu'etre negative, aucune base de 
donnees n'etant specifiee. En revanche, si le demandeur souhaite 
demarrer la base de donnees de facturation de Louveciennes, une 
reponse peut etre apportee suivant le role et les privileges du 
demandeur ; 

• il existe au moins une permission configuree qui correspond a la 
permission demandee ; le RAC utilise le critere de controle d'acces 
pour identifier une ressource afin d'effectuer la comparaison des 
permissions demandees aux permissions configurees ; 

• le champ consultation du domaine de validite a pour valeur oui. ce 
qui signifie qu'il faut verifier le domaine de validite, Taction etant 
restreinte a un sous-ensemble de la totalite des ressources. 
Lorsqu'un domaine de validite est associe a un role et que le 
champ consultation du domaine de validite a pour valeur oui. tout 
demandeur disposant de ce role n'accede ou n'agit que sur des 
ressources du domaine de validite 

Si les trois conditions sont reunis, le RAC 6 compare Tidentifiant de 
la ressource dans la question posee au domaine de validite du role retrouve 
dans les moyens de stockage 10 par le module 9 comme vu plus haut. 

Si le domaine de validite ne correspond pas a la ressource en 
question, les conditions d'obtention du droit ne sont pas remplies et le RAC 
6 repond a I'entite 4 appelante via TAP I 5 que Tutilisateur n'a pas le droit de 
realiser Taction demandee. 

Si le domaine de validite correspond a la ressource en question, 
les conditions d'obtention du droit sont remplies et le RAC 6 repond a Tentite 
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4 appelante via TAP I 5 que I'utilisateur a le droit de realiser Taction 
demandee. 

Dans Texemple de la description, le precede compare la ressource 
base de donnees de facturation de Louveciennes dont le nom est 
« database_facturation.frlv.bull.fr » au domaine de validite du role 
administrateur de base de donnees qui est constitue des bases de donnees 
dont le nom finit par frlv.bull.fr a savoir « *.frlv. bull.fr ». La ressource base de 
donnees de facturation de Louveciennes a un nom qui finit par frlv.bull.fr: 
elle appartient done au domaine de validite. L'entite 4 appelante autorise 
Tadministrateur 7 a arreter la base de donnees de facturation de 
Louveciennes. 

II est a souligner que ; 

• les permissions sont independantes des demandeurs : les 
permissions sont accordees ou refusees suivant le role et les 
privileges du demandeur ; 

• le controle d'acces ne necessite pas d'acces physique aux 
ressources : un filtrage d'actions est realise avant tout acces ; 

• le dispositif de controle d'acces est rapide. De plus, le dispositif et 
le precede selon ['invention offrent une optimisation du controle 
d'acces. 

La presente invention concerne le precede de controle d'acces du 
demandeur 7 a des ressources 2d dans le systeme informatique 1, 
caracterise en ce qu'il consiste a definir des roles recouvrant un ou plusieurs 
privileges et representant une competence du demandeur pour realiser des 
taches specifiques, a enregistrer les roles definis dans les moyens 10,12 de 
stockage, et a enregistrer la liste de controle d'acces definissant les 
conditions d'obtention d'un droit sur un type de ressource, a savoir d'une 
permission configuree en terme de privileges dans lesdits moyens 10,12. 
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Le procede effectue le controle d'acces du demandeur 7 a des 
ressources 2d sans acceder auxdites ressources 2d. 

Le procede effectue un controle d'acces a deux niveaux : 

• un premier sur le type des ressources 2d ; 

• un deuxieme niveau sur lldentifiant des ressources 2d. 

Le procede consiste a : 

• identifier le demandeur ainsi que son role et ses privileges ; 

• comparer les privileges et les permissions demandees par le 
demandeur avec les privileges requis et permissions configurees 
enregistres dans les moyens 10 de stockage et ; 

• autoriser Taction requise sur la ressource concernee lorsque des 
permissions demandees et configurees correspondent et que Tun des 
privileges requis correspond au privilege de Tentite. 

Le procede consiste a restreindre a une partie des ressources 
seulement les ressources accessibles pour un role donne au moyen d'un 
domaine de validite, et a enregistrer les domaines de validite constitues 
dans les moyens de stockage 1 0. 

Le procede consiste a consulter une information enregistree dans les 
moyens de stockage 10 relative a la necessite de consulter le domaine de 
validite et a verifier que la ressource concernee appartient au domaine de 
validite seulement si ladite information le requiert. 

Le procede consiste a regrouper des droits ou des ressources en 
groupes generiques representes par des caracteres speciaux ou mots-cles 
ou autres. 
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La presente invention concerne egalement le dispositif susceptible de 
mettre en oeuvre le procede decrit ci-dessus. 

La presente invention se rapporte au dispositif de controle d'acces du 
demandeur a des ressources 2d dans le systeme informatique 1. caracterise 
en ce qu'il comprend la machine 2a d'administration comportant le service 
de controle d'acces. le RAC 6 et ies moyens de stockage 10 de roles, 
privileges et listes de controle d'acces. 
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REVENDICATIONS 

1. Precede de controle d'acces d'un demandeur (7) a des ressources (2d) 
dans un systeme informatique (1), caracterise en ce qu'il consiste a definir 
des roles recouvrant un ou plusieurs privileges et representant une 
competence du demandeur pour realiser des taches specifiques, a 
enregistrer les roles definis dans des moyens (10,12) de stockage. et a 
enregistrer une liste de controle d*acces definissant les conditions 
d'obtention d'un droit sur un type de ressource, a savoir d'une permission 
configuree en terme de privileges dans lesdits moyens (10,12). 

2. Precede selon la revendication 1, caracterise en ce qu'il effectue le 
controle d'acces du demandeur (7) a des ressources (2d) sans acceder 
auxdites ressources (2d). 

3. Precede selon Tune des revendications 1 ou 2, caracterise en ce qu'il 
effectue un controle d'acces a deux niveaux : 

« un premier sur le type des ressources (2d) ; 

• un deuxieme niveau sur ridentifiant des ressources (2d). 

4. Precede selon Tune des revendications 1 a 3, caracterise en ce qu'il 
consiste a : 

• identifier le demandeur ainsi que son role et ses privileges ; 

• comparer les privileges et les permissions demandees par le 
demandeur avec les privileges requis et permissions configurees 
enregistres dans les moyens (10) de stockage et ; 

• autoriser Taction requise sur la ressource concernee lorsque des 
permissions demandees et configurees correspondent et que Tun des 
privileges requis correspond au privilege de Tentite. 
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5. Precede selon Tune des revendications 1 a 4, caracterise en ce qu'il 
consiste a restreindre a una partie des ressources seulement les ressources 
accessibles pour un role donne au moyen d'un domaine de validite, et a 
enregistrer les domaines de validite constitues dans les moyens de stockage 
(10). 

6. Precede selon la revendication 5, caracterise en ce qu'il consiste a 
consulter une information enregistree dans les moyens de stockage (10) 
relative a la necessite de consulter le domaine de validite et a verifier que la 
ressource concernee appartient au domaine de validite seulement si ladite 
information le requiert. 

7. Precede selon Tune des revendications 1 a 6, caracterise en ce qu'il 
consiste a regrouper des droits ou des ressources en groupes generiques 
representes par des caracteres speciaux ou mots-cles ou autres, 

8. Dispositif de controle d'acces d'un demandeur a des ressources (2d) dans 
un systeme informatique (1), caracterise en ce qu'il comprend une machine 
(2a) d'administration comportant un sen/ice de controle d'acces, ie RAC (6) 
et des moyens de stockage (10) de roles, privileges et listes de controle 
d'acces. 

9. Dispositif permettant la mise en oeuvre du precede selon Tune des 
revendications 1 a 7, 
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